Software Engineer vs. System ****yst - Software-Eng

This is a discussion on Software Engineer vs. System ****yst - Software-Eng ; Dear All, What is the difference between Software Engineer and System ****yst?! What is the difference between Software engineering and System ****ysis and design??! Best regards,...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 10 of 18

Software Engineer vs. System ****yst

  1. Default Software Engineer vs. System ****yst

    Dear All,

    What is the difference between Software Engineer and System ****yst?!
    What is the difference between Software engineering and System
    ****ysis and design??!

    Best regards,


  2. Default Re: Software Engineer vs. System ****yst

    Motaz K. Saad wrote:

    > What is the difference between Software Engineer and System ****yst?!
    > What is the difference between Software engineering and System
    > ****ysis and design??!


    Who is asking? To what use will you put the answer?

    In some shops, "systems ****yst" means someone who designs code on paper,
    but doesn't implement it. That's a bad practice, because the people who _do_
    have to implement it invariably must work harder for less money. So the term
    "systems ****yst" is generally out of favor.

    A "software engineer" is just like any other engineer: Someone who applies
    the results of scientific research to efficiently solve business problems.
    In our case, the research is "computer science".

    So "software engineering" naturally includes designing the software; drawing
    diagrams of its objects, and tables of its inputs and outputs.

    --
    Phlip
    http://www.greencheese.us/ZeekLand <-- NOT a blog!!!



  3. Default Re: Software Engineer vs. System ****yst

    On Feb 25, 5:29 pm, "Motaz K. Saad" <motaz.s...{}> wrote:
    > Dear All,
    >
    > What is the difference between Software Engineer and System ****yst?!
    > What is the difference between Software engineering and System
    > ****ysis and design??!

    There aren't standard definitions of these terms.

    In general practice a systems ****yst is an expert on requirements
    engineering and problem ****ysis. They understand the problem domain
    very deeply and the solution domain (i.e. software technology) less
    deeply. Their primary responsibility is to understand the problem to
    be solved and capture this as well written, testable requirements.

    The software engineers are those who are experts on software
    technology and have a reasonable knowledge of the problem domain, but
    probably understand it less deeply than the ****yst. The software
    engineers' primary responsibility is to create a system that works and
    meets the requirements.

    In practice however, totally non-technical ****ysts are rarely
    effective because they don't understand what is and isn't possible (or
    how difficult something is). Similarly if the software engineers
    don't have enough domain knowledge and can't talk directly to people
    in the problem domain, things are unlikely to go well. In particular,
    the software architects (aka chief engineers aka technical leads) need
    to be able to bridge this gap from solution to problem domain very
    effectively.

    It would be fair to say that in many places these two roles have been
    merged together. Agile development particularly stresses this.

    Eoin.



  4. Default Re: Software Engineer vs. System ****yst

    Responding to Saad...

    > What is the difference between Software Engineer and System ****yst?!
    > What is the difference between Software engineering and System
    > ****ysis and design??!


    I suspect you really mean Systems Engineer rather than Systems ****yst
    since there is no software design in Systems ****ysis.

    As Woods explained, a Systems ****yst is concerned with requirements
    specification. The term is pretty much obsolete today because it was
    coined back in the days of Structured Development. SD was very much
    focused on the hardware computational models. The problem was that
    customer domains generally are not as rigorously defined as the
    computing space so requirements tended to get garbled by the time they
    were implemented by the developers.

    So the position of Systems ****yst was developed to essentially convert
    the customer's natural language specification into a complete, precise,
    and unambiguous requirements specification. The developers would then
    presumably have no difficulty converting that specification to correct
    software. Thus the Systems ****yst was supposed to be a domain expert
    who also understood some rigorous notation for specifying the requirements.

    Alas, in practice that was a problem because the only notations around
    that were sufficiently rigorous and were readily mappable to the
    computing space were those already used by the software designers. As a
    result the Systems ****yst typically overspecified the requirements by
    also defining the software design. Since knowledge of the computing
    space was a <very> secondary requirement for the Systems ****yst, this
    often led to Big Problems.

    The term I suspect you meant was Systems Engineer. A Systems Engineer is
    responsible for defining the large scale structure of the software
    (i.e., application partitioning) and the appropriate technical
    infrastructures (e.g., OS, J2EE, XML, TCP/IP, etc.) to be employed in
    the development. The most important job of the Systems Engineer is to
    allocate the problem requirements to specific subsystems and define the
    interfaces between subsystems. Then the subsystems can be developed in a
    quasi-independent fashion by different developer teams.

    Unfortunately Software Engineer has been so broadly used that it has
    become synonymous with "software developer". Historically, though, the
    term referred to someone who was concerned with the /process/ of
    developing software rather than the software itself. IOW, the people who
    design and understand how to apply processes and process frameworks like
    RUP, CMM, and XP are software engineers.


    *************
    There is nothing wrong with me that could
    not be cured by a capful of Drano.

    H. S. Lahman
    hsl{}pathfindermda.com
    Pathfinder Solutions
    http://www.pathfindermda.com
    blog: http://pathfinderpeople.blogs.com/hslahman
    "Model-Based Translation: The Next Step in Agile Development". Email
    info{}pathfindermda.com for your copy.
    Pathfinder is hiring:
    http://www.pathfindermda.com/about_us/careers_pos3.php.
    (888)OOA-PATH




  5. Default Re: Software Engineer vs. System ****yst

    On Feb 26, 6:05 pm, "H. S. Lahman" <h.lah...{}verizon.net> wrote:
    > Responding to Saad...
    >
    > > What is the difference between Software Engineer and System ****yst?!
    > > What is the difference between Software engineering and System
    > > ****ysis and design??!

    >
    > I suspect you really mean Systems Engineer rather than Systems ****yst
    > since there is no software design in Systems ****ysis.
    >
    > As Woods explained, a Systems ****yst is concerned with requirements
    > specification. The term is pretty much obsolete today because it was
    > coined back in the days of Structured Development. SD was very much
    > focused on the hardware computational models. The problem was that
    > customer domains generally are not as rigorously defined as the
    > computing space so requirements tended to get garbled by the time they
    > were implemented by the developers.
    >
    > So the position of Systems ****yst was developed to essentially convert
    > the customer's natural language specification into a complete, precise,
    > and unambiguous requirements specification. The developers would then
    > presumably have no difficulty converting that specification to correct
    > software. Thus the Systems ****yst was supposed to be a domain expert
    > who also understood some rigorous notation for specifying the requirements.
    >
    > Alas, in practice that was a problem because the only notations around
    > that were sufficiently rigorous and were readily mappable to the
    > computing space were those already used by the software designers. As a
    > result the Systems ****yst typically overspecified the requirements by
    > also defining the software design. Since knowledge of the computing
    > space was a <very> secondary requirement for the Systems ****yst, this
    > often led to Big Problems.
    >
    > The term I suspect you meant was Systems Engineer. A Systems Engineer is
    > responsible for defining the large scale structure of the software
    > (i.e., application partitioning) and the appropriate technical
    > infrastructures (e.g., OS, J2EE, XML, TCP/IP, etc.) to be employed in
    > the development. The most important job of the Systems Engineer is to
    > allocate the problem requirements to specific subsystems and define the
    > interfaces between subsystems. Then the subsystems can be developed in a
    > quasi-independent fashion by different developer teams.
    >
    > Unfortunately Software Engineer has been so broadly used that it has
    > become synonymous with "software developer". Historically, though, the
    > term referred to someone who was concerned with the /process/ of
    > developing software rather than the software itself. IOW, the people who
    > design and understand how to apply processes and process frameworks like
    > RUP, CMM, and XP are software engineers.
    >
    > *************
    > There is nothing wrong with me that could
    > not be cured by a capful of Drano.
    >
    > H. S. Lahman
    > h...{}pathfindermda.com
    > Pathfinder Solutionshttp://www.pathfindermda.com
    > blog:http://pathfinderpeople.blogs.com/hslahman
    > "Model-Based Translation: The Next Step in Agile Development". Email
    > i...{}pathfindermda.com for your copy.
    > Pathfinder is hiring:http://www.pathfindermda.com/about_us/careers_pos3.php.
    > (888)OOA-PATH


    First of all, thanks for everyone replied this discussion. I can say
    that you all share the same point about software engineering and
    system ****ysis and design.
    Let us take a look for the table of content (TOC) of these subjects:

    1. System ****ysis and Design Textbook:

    Title: Modern Systems ****ysis and Design, 4/E
    Authors:
    Jeffrey A. Hoffer, University of Dayton
    Joey F. George, Florida State University
    Joseph S. Valacich, Washington State University
    Publisher: Prentice Hall
    Copyright: 2005
    ISBN-10: 0131454617
    ISBN-13: 9780131454613
    Table of Contents

    I. FOUNDATIONS FOR SYSTEMS DEVELOPMENT.
    1. The Systems Development Environment.
    2. The Origins of Software.
    3. Managing the Information Systems Project.

    II. PLANNING.
    4. Identifying and Selecting Systems Development Projects.
    5. Initiating and Planning Development Projects.

    III. ****YSIS.
    6. Determining System Requirements.
    7. Structuring System Process Requirements.
    8. Structuring System Logic Requirements.
    9. Structuring System Data Requirements.

    IV. DESIGN.
    10. Designing Databases.
    11. Designing Forms and Reports.
    12. Designing Interfaces and Dialogues.
    13. Finalizing Design Specifications.
    14. Designing Distributed and Internet Systems.
    V. IMPLEMENTATION AND MAINTENANCE.
    15. Implementing Systems.
    16. Maintaining Information Systems.

    Appendix 1. Succeeding as a Systems ****yst.
    Appendix 2. Automated Tools for Systems Development.
    Appendix 3. Object-Oriented ****ysis and Design.
    __________________________________________

    2. Software engineering Textbook:
    Title: Software Engineering, 8/E
    Author: Ian Sommerville
    Publisher: Addison-Wesley
    Copyright: 2006
    ISBN-10: 0321313798
    ISBN-13: 9780321313799
    Table of Contents

    INTRODUCTION
    Ch 1: Introduction
    Ch 2: Socio-technical Systems
    Ch 3: Dependability
    Ch 4: Software Processes
    Ch 5: Project Management

    REQUIREMENTS ENGINEERING
    Ch 6: Software Requirements
    Ch 7: RE Processes
    Ch 8: Systems Models
    Ch 9: Critical Systems Specification
    Ch 10: Formal Specification

    DESIGN
    Ch 11: Architectural Design
    Ch 12: Distributed Systems Architecture
    Ch 13: Application Architectures
    Ch 14: Object-oriented Design
    Ch 15: Real-time Systems
    Ch 16: User Interface Design

    SOFTWARE DEVELOPMENT
    Ch 17: Iterative Software Development
    Ch 18: Software Reuse
    Ch 19: CBSE
    Ch 20: Critical Systems Development
    Ch 21: Software Evolution

    VERIFICATION AND VALIDATION
    Ch 22: Verification and Validation
    Ch 23: Software Testing
    Ch 24: Critical Systems Validation

    MANAGEMENT
    Ch 25: Managing People
    Ch 26: Software Cost Estimation
    Ch 27: Quality Management
    Ch 28: Process Improvement
    Ch 29: Configuration Management

    EMERGING TECHNOLOGIES
    Ch 30: Security Engineering
    Ch 31: Service-oriented Software Engineering
    Ch 32: Aspect-oriented Software Development
    _________________________________________

    Compare :
    1. ****YSIS in System ****ysis and Design Textbook and REQUIREMENTS
    ENGINEERING in Software engineering Textbook.
    2. DESIGN in System ****ysis and Design Textbook and DESIGN in
    Software engineering Textbook.

    I think System System ****ysis and Design Textbook is concerned about
    project planning and management (people, resources management, and
    feasibility study) it is also concerned about the information system.
    in ****ysis phase is concerned about SYSTEM requirement.
    on the other hand, Software engineering Textbook is concerned about
    SOFTWARE Requirement & Requirement Engineering (RE) Process, System
    Models (UML), and formal specification.

    In Design phase, System System ****ysis and Design Textbook talks
    about database design, forms and reports Design (GUI). on the other
    hand, Software engineering Textbook talks about Architectural Design,
    Application Architectures, Object-oriented Design, Real-time Systems,
    User Interface Design


    I did not heard about System ****yst jobs, but I heard about Software
    Engineer jobs [ http://www.google.com/jobs/ , http://sourceforge.net/jobs/
    ]


    What do you think?


  6. Default Re: Software Engineer vs. System ****yst

    On Feb 25, 8:46 pm, "Phlip" <phlip...{}yahoo.com> wrote:
    > Motaz K. Saad wrote:
    > > What is the difference between Software Engineer and System ****yst?!
    > > What is the difference between Software engineering and System
    > > ****ysis and design??!

    >
    > Who is asking? To what use will you put the answer?
    >
    > In some shops, "systems ****yst" means someone who designs code on paper,
    > but doesn't implement it. That's a bad practice, because the people who _do_
    > have to implement it invariably must work harder for less money. So the term
    > "systems ****yst" is generally out of favor.

    Do you mean in this case we need System ****yst and Programmer to
    produce a software?
    >
    > A "software engineer" is just like any other engineer: Someone who applies
    > the results of scientific research to efficiently solve business problems.
    > In our case, the research is "computer science".
    >
    > So "software engineering" naturally includes designing the software; drawing
    > diagrams of its objects, and tables of its inputs and outputs.

    Can System ****yst and Programmer be replaced by Software Engineer?
    >
    > --
    > Phlip
    > http://www.greencheese.us/ZeekLand<-- NOT a blog!!!




  7. Default Re: Software Engineer vs. System ****yst

    On Feb 26, 10:55 am, "Eoin Woods" <eoinwo...{}> wrote:
    > On Feb 25, 5:29 pm, "Motaz K. Saad" <motaz.s...{}> wrote:> Dear All,
    >
    > > What is the difference between Software Engineer and System ****yst?!
    > > What is the difference between Software engineering and System
    > > ****ysis and design??!

    >
    > There aren't standard definitions of these terms.
    >
    > In general practice a systems ****yst is an expert on requirements
    > engineering and problem ****ysis. They understand the problem domain
    > very deeply and the solution domain (i.e. software technology) less
    > deeply. Their primary responsibility is to understand the problem to
    > be solved and capture this as well written, testable requirements.

    notice that requirement engineering is mentioned in software
    engineering textbook, and never mentioned in modern system ****ysis
    and design textbook.
    >
    > The software engineers are those who are experts on software
    > technology and have a reasonable knowledge of the problem domain, but
    > probably understand it less deeply than the ****yst. The software
    > engineers' primary responsibility is to create a system that works and
    > meets the requirements.

    this means we need system ****yst and software engineer to produce a
    software!?
    >
    > In practice however, totally non-technical ****ysts are rarely
    > effective because they don't understand what is and isn't possible (or
    > how difficult something is). Similarly if the software engineers
    > don't have enough domain knowledge and can't talk directly to people
    > in the problem domain, things are unlikely to go well. In particular,
    > the software architects (aka chief engineers aka technical leads) need
    > to be able to bridge this gap from solution to problem domain very
    > effectively.
    >
    > It would be fair to say that in many places these two roles have been
    > merged together. Agile development particularly stresses this.
    >
    > Eoin.




  8. Default Re: Software Engineer vs. System ****yst

    On Feb 26, 6:05 pm, "H. S. Lahman" <h.lah...{}verizon.net> wrote:
    > Responding to Saad...
    >
    > > What is the difference between Software Engineer and System ****yst?!
    > > What is the difference between Software engineering and System
    > > ****ysis and design??!

    >
    > I suspect you really mean Systems Engineer rather than Systems ****yst
    > since there is no software design in Systems ****ysis.

    but modern system ****ysis and design text book talked about design.
    >
    > As Woods explained, a Systems ****yst is concerned with requirements
    > specification. The term is pretty much obsolete today because it was
    > coined back in the days of Structured Development. SD was very much
    > focused on the hardware computational models. The problem was that
    > customer domains generally are not as rigorously defined as the
    > computing space so requirements tended to get garbled by the time they
    > were implemented by the developers.
    >
    > So the position of Systems ****yst was developed to essentially convert
    > the customer's natural language specification into a complete, precise,
    > and unambiguous requirements specification. The developers would then
    > presumably have no difficulty converting that specification to correct
    > software. Thus the Systems ****yst was supposed to be a domain expert
    > who also understood some rigorous notation for specifying the requirements.
    >
    > Alas, in practice that was a problem because the only notations around
    > that were sufficiently rigorous and were readily mappable to the
    > computing space were those already used by the software designers. As a
    > result the Systems ****yst typically overspecified the requirements by
    > also defining the software design. Since knowledge of the computing
    > space was a <very> secondary requirement for the Systems ****yst, this
    > often led to Big Problems.
    >
    > The term I suspect you meant was Systems Engineer. A Systems Engineer is
    > responsible for defining the large scale structure of the software
    > (i.e., application partitioning) and the appropriate technical
    > infrastructures (e.g., OS, J2EE, XML, TCP/IP, etc.) to be employed in
    > the development. The most important job of the Systems Engineer is to
    > allocate the problem requirements to specific subsystems and define the
    > interfaces between subsystems. Then the subsystems can be developed in a
    > quasi-independent fashion by different developer teams.
    >
    > Unfortunately Software Engineer has been so broadly used that it has
    > become synonymous with "software developer". Historically, though, the
    > term referred to someone who was concerned with the /process/ of
    > developing software rather than the software itself. IOW, the people who
    > design and understand how to apply processes and process frameworks like
    > RUP, CMM, and XP are software engineers.
    >
    > *************
    > There is nothing wrong with me that could
    > not be cured by a capful of Drano.
    >
    > H. S. Lahman
    > h...{}pathfindermda.com
    > Pathfinder Solutionshttp://www.pathfindermda.com
    > blog:http://pathfinderpeople.blogs.com/hslahman
    > "Model-Based Translation: The Next Step in Agile Development". Email
    > i...{}pathfindermda.com for your copy.
    > Pathfinder is hiring:http://www.pathfindermda.com/about_us/careers_pos3.php.
    > (888)OOA-PATH




  9. Default Re: Software Engineer vs. System ****yst

    Responding to Saad...

    > Let us take a look for the table of content (TOC) of these subjects:
    >
    > 1. System ****ysis and Design Textbook:
    >
    > Title: Modern Systems ****ysis and Design, 4/E
    > Authors:
    > Jeffrey A. Hoffer, University of Dayton
    > Joey F. George, Florida State University
    > Joseph S. Valacich, Washington State University
    > Publisher: Prentice Hall
    > Copyright: 2005
    > ISBN-10: 0131454617
    > ISBN-13: 9780131454613
    > Table of Contents
    >
    > I. FOUNDATIONS FOR SYSTEMS DEVELOPMENT.
    > 1. The Systems Development Environment.
    > 2. The Origins of Software.
    > 3. Managing the Information Systems Project.
    >
    > II. PLANNING.
    > 4. Identifying and Selecting Systems Development Projects.
    > 5. Initiating and Planning Development Projects.
    >
    > III. ****YSIS.
    > 6. Determining System Requirements.
    > 7. Structuring System Process Requirements.
    > 8. Structuring System Logic Requirements.
    > 9. Structuring System Data Requirements.
    >
    > IV. DESIGN.
    > 10. Designing Databases.
    > 11. Designing Forms and Reports.
    > 12. Designing Interfaces and Dialogues.
    > 13. Finalizing Design Specifications.
    > 14. Designing Distributed and Internet Systems.
    > V. IMPLEMENTATION AND MAINTENANCE.
    > 15. Implementing Systems.
    > 16. Maintaining Information Systems.
    >
    > Appendix 1. Succeeding as a Systems ****yst.
    > Appendix 2. Automated Tools for Systems Development.
    > Appendix 3. Object-Oriented ****ysis and Design.
    > __________________________________________
    >
    > 2. Software engineering Textbook:
    > Title: Software Engineering, 8/E
    > Author: Ian Sommerville
    > Publisher: Addison-Wesley
    > Copyright: 2006
    > ISBN-10: 0321313798
    > ISBN-13: 9780321313799
    > Table of Contents
    >
    > INTRODUCTION
    > Ch 1: Introduction
    > Ch 2: Socio-technical Systems
    > Ch 3: Dependability
    > Ch 4: Software Processes
    > Ch 5: Project Management
    >
    > REQUIREMENTS ENGINEERING
    > Ch 6: Software Requirements
    > Ch 7: RE Processes
    > Ch 8: Systems Models
    > Ch 9: Critical Systems Specification
    > Ch 10: Formal Specification
    >
    > DESIGN
    > Ch 11: Architectural Design
    > Ch 12: Distributed Systems Architecture
    > Ch 13: Application Architectures
    > Ch 14: Object-oriented Design
    > Ch 15: Real-time Systems
    > Ch 16: User Interface Design
    >
    > SOFTWARE DEVELOPMENT
    > Ch 17: Iterative Software Development
    > Ch 18: Software Reuse
    > Ch 19: CBSE
    > Ch 20: Critical Systems Development
    > Ch 21: Software Evolution
    >
    > VERIFICATION AND VALIDATION
    > Ch 22: Verification and Validation
    > Ch 23: Software Testing
    > Ch 24: Critical Systems Validation
    >
    > MANAGEMENT
    > Ch 25: Managing People
    > Ch 26: Software Cost Estimation
    > Ch 27: Quality Management
    > Ch 28: Process Improvement
    > Ch 29: Configuration Management
    >
    > EMERGING TECHNOLOGIES
    > Ch 30: Security Engineering
    > Ch 31: Service-oriented Software Engineering
    > Ch 32: Aspect-oriented Software Development
    > _________________________________________
    >
    > Compare :
    > 1. ****YSIS in System ****ysis and Design Textbook and REQUIREMENTS
    > ENGINEERING in Software engineering Textbook.
    > 2. DESIGN in System ****ysis and Design Textbook and DESIGN in
    > Software engineering Textbook.


    The Hoffer book is much more focused on requirements. Even the chapters
    on "design" are really about things like user interface design and
    database schemas, which are specifications outside of a software
    application. For example, a GUI design is basically a requirements
    specification for the application UI. Similarly, forms and reports are
    essentially requirements specifications for the application's inputs and
    outputs. Modern databases, particularly RDBs, are designed to be
    independent of specific applications. So it would be a Systems ****yst's
    job to define database schemas to be shared by multiple applications.
    IOW, I think Hoffer et al have a rather restricted definition of
    "design". (But I'll bet they are quite explicit about that somewhere
    early in the book.)

    Note that the Hoffer book doesn't seem to have much to say about things
    like system partitioning and specifications of technologies. Those would
    be the province of Systems Engineering. Instead the authors stick pretty
    much to requirements specification, which is the classic Systems
    ****ysis realm.

    In contrast, the Somerville book is much broader in scope and covers the
    full breadth of software development. The chapters on Design are about
    classic application design.

    > I think System System ****ysis and Design Textbook is concerned about
    > project planning and management (people, resources management, and
    > feasibility study) it is also concerned about the information system.
    > in ****ysis phase is concerned about SYSTEM requirement.
    > on the other hand, Software engineering Textbook is concerned about
    > SOFTWARE Requirement & Requirement Engineering (RE) Process, System
    > Models (UML), and formal specification.


    Actually, I think Sommerville's book is probably more focused on project
    management. Note that he has entire sections dedicated to Development
    and Validation, which are clearly closely linked to project management.
    (Though it is tough to tell just from a TOC.)


    *************
    There is nothing wrong with me that could
    not be cured by a capful of Drano.

    H. S. Lahman
    hsl{}pathfindermda.com
    Pathfinder Solutions
    http://www.pathfindermda.com
    blog: http://pathfinderpeople.blogs.com/hslahman
    "Model-Based Translation: The Next Step in Agile Development". Email
    info{}pathfindermda.com for your copy.
    Pathfinder is hiring:
    http://www.pathfindermda.com/about_us/careers_pos3.php.
    (888)OOA-PATH




  10. Default Re: Software Engineer vs. System ****yst

    On Feb 28, 6:02 am, "Motaz K. Saad" <motaz.s...{}> wrote:
    > Do you mean in this case we need System ****yst and Programmer to
    > produce a software?
    >
    > Can System ****yst and Programmer be replaced by Software Engineer?

    You need both roles (problem ****ysis, solution implementation)
    fulfilled, possibly by the same person.

    In fact, both roles are software engineering, they're just different
    specialisations.

    Eoin.


+ Reply to Thread
Page 1 of 2 1 2 LastLast

Similar Threads

  1. Replies: 0
    Last Post: 10-18-2007, 09:27 PM
  2. Replies: 1
    Last Post: 10-08-2007, 02:37 PM
  3. Replies: 0
    Last Post: 10-08-2007, 01:29 PM
  4. Replies: 0
    Last Post: 10-08-2007, 01:17 PM
  5. Replies: 0
    Last Post: 10-08-2007, 12:56 PM